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Abstract — This report describes a Secure, Autonomous, and 
Intelligent Controller for Integrating Distributed Emergency 
Response Satellite Operations. It includes a description of 
current improvements to existing Virtual Mission Operations 
Center technology being used by US Department of Defense 
and originally developed under NASA funding. The report 
also highlights a technology demonstration performed in 
partnership with the United States Geological Service for 
Earth Resources Observation and Science using DigitalGlobe® 
satellites to obtain space-based sensor data. 
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1. Objective 

The United States Geological Service (USGS) Center for 
Earth Resources Observation and Science (EROS) Hazards 
Data Distribution System (HDDS) aims at providing a 
unified system of space data acquisition and delivery to 
those affected by natural or man-made disasters. The 
HDDS stores and provides dissemination access to a host of 
satellite and aerial data provider assets. Operations of these 
assets, critical to the success of disaster relief efforts 
worldwide, can be hampered by the lack of systems 
interoperability and automation, driving up the cost of 
providing services and interfering with the ability of the 
HDDS to provide timely data products. In conjunction with 
multiple government agencies and the United States 
Department of Defense (DOD), this task was aimed at 
applying the technology and lessons learned from multiple 
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NASA Earth Science Technology Office (ESTO) Advanced 
Information Systems Technology (AIST) development tasks 
[1-3]. The goal was to automate the coordination and 
acquisition of Earth observing resource data from a wide 
variety of sources (potentially national, international, 
commercial, NASA, and DOD). Lessons learned from this 
task and associated demonstrations have been provided to 
the International Charter of Space and Major Disasters and 
the general emergency response remote sensing community. 
Additionally, the newly created “web-based service” may be 
considered for a part of the larger Working Group on 
Information Systems and Services (WGISS) architecture. 

2. Background 

NASA GRC pioneered the initial Virtual Mission 
Operations Center (VMOC) concept. Initial concepts were 
first demonstrated in November 2000 at NASA Johnson 
Space Center’s (JSC) Inspection 2000 which allowed the 
public, industry, and other NASA organizations to view 
NASA technologies that were being or could be applied to 
Earthbound applications. Here, GRC, Goddard Space Flight 
Center (GSFC), JSC, and Veridian demonstrated secure, 
virtual, end-to-end mission operations over the Internet and 
NASA’s Tracking and Data Relay Satellite System 
(TDRSS). 

Working closely with General Dynamics - Advanced 
Information System (GD-AIS) (which acquired Veridian), 
Surrey Satellite Technology, the USA Space and Missile 
Defense Battle Lab, Universal Space Network (USN), the 
14th Air Force, Joint Space Operations Center (JSpOC), Air 
Force Information Warfare Center, and numerous other 
companies, VMOC was developed, tested, and real-time 
commanding of a space asset was demonstrated in June of 
2004. Included as part of this demonstration was the first 
secure, survivable, virtual mission operations and 
commanding of an element in space and the first secure, 
mobile retrieval of data from a sophisticated space-based 
system by remote, mobile users. The new technologies 
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allowed non-space professionals to indirectly perform 
command and control of satellite assets. 

ESTO’s Advanced Technology Insertion (ATI) program 
provided funding to enhance the VMOC via the Secure 
Autonomous Automated Scheduling (SAAS) project. The 
SAAS objective was to monitor the United States 
Geological Survey (USGS) earthquake notification system, 
and have the General Dynamics (GD) developed VMOC 
located at NASA’s Glenn Research Center (GRC) 
automatically schedule an image acquisition of the target 
area using via the Surrey Satellite Technology Ltd (SSTL), 
United Kingdom Disaster Monitoring Constellation- 1 
(UKDMC-1) satellite and download the acquired image via 
USN’s ground terminals. The goal was to reduce the time 
between notification and availability of the image by using 
multiple ground stations with both schedule upload and 
payload download capability as well as demonstrate the 
ability to perform secure autonomous automated scheduling 
of on-orbit assets, triggered by available sensor webs (Tip 
and Cue). The UK-DMC’s availability was obtained via 
machine-to-machine communications using SSTL’s mission 
planning system. Access to/from the UK-DMC was via 
SSTL’s and Universal Space Networks’ (USN) ground 
assets. The availability and scheduling of USN’s assets was 
also performed autonomously via machine-to-machine 
communications. All communication was via open Internet 
standards both on the ground and between ground and 
space. Although machine-to-machine scheduling was 
performed, this was performed using a mirror of SSTL’s 
operational Mission Planning System. Full autonomous 
operation for VMOC to SSTL scheduler (MPS) to actual 
commanding of the space asset was not achieved due to 
funding limitations. SSTL required additional funding to 
add such automation into their mission planning system 
(machine-to-machine remote request to autonomous data 
delivery). 

VMOC is currently the sole tasking tool for two DoD 
satellites (TacSat4 and ORS-1) and is being evaluated for 
use by the USGS for data generation in response to disasters 
and NGA for acquisition of commercial satellite imagery in 
support of the DoD. 

3. VMOC Details 

For purposes of this task, earlier generation VMOC 
hardware and software housed at NASA Glenn Research 
Center (GRC) were upgraded with the appropriate software 
licenses and tools to provide a stable, secure, virtual front 
end for mission services, automated operations, data 
dissemination, and visualization. Additionally, key 
Advanced Information System Technology (AIST) funded 
Real Time Mission Monitor (RTMM) and technologies 
provided by the other DoD and EROS team members were 
also considered for introduction to the integrated system to 
allow new operations concepts to be developed and quickly 
fielded. Satellite services were automated and demonstrated 
using the integrated tool set. 


Some of the detailed items that were added to the existing 
VMOC include: 

• Ad hoc tasking generation 

• Collection requirement management 

o Rules based recurring tasking to meet higher 
level objectives 

• Coordinated constellation-level scheduling of multiple 
space assets 

o Use of live and simulated missions within the 
constellation 

• Dynamic real-time modification to the constellation 
schedule based on real-time events 

• Account management of assets 

o Management of collections and data products 
on an asset by asset basis 

o Human-in-the-loop release of requests to data 
providers 

• Machine-to-machine interfaces for space-based sensor 
assets 

o Interface support to DigitalGlobe 
o Automated tasking submission to DigitalGlobe 
o Automated accounting of product delivery 
o Access to live RTMM support 

It is important to note that NASA was able to leverage 
millions of dollars in DOD investments to the original 
NASA VMOC. Licensing of the DOD VMOC govemment- 
off-the-shelf (GOTS) technology was agreed upon between 
GD-AIS and the US Naval Research Lab (NRL). Thus, 
GOTS code related to the VMOC was used in this project. 

In return, system development for the NASA demonstration 
will be incorporated into the NRL core VMOC and will 
become part of the GOTS code. As a part of this 
arrangement it was agreed that all NASA-related VMOC 
code enhancement would be evaluated with regards to 
impact to the VMOC security accreditation. The DOD 
accreditation took nearly two years to complete. This is the 
reason why it was so important to NOT do anything to the 
NASA VMOC that would perturb the existing accreditation 
- see Space Asset Selection. 

3. 1 Hardware and Software 

As with the previous SAAS demonstration, the VMOC 
consists of a Mission VMOC utilized for tasking, 
scheduling, Space Situational Awareness and Information 
Management. The system consists of a rack-mounted 
chassis that houses modules interconnected through a 
standard Internet connection. The computer interfaces to 
other platforms and equipment via standard connectors and 
cabling. The physical system resides at Glenn Research 
Center in Cleveland Ohio and has a connection via the open 
Internet to field users [Figure 1]. 
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Figure 2 - Great Lakes Operations Center (VMOC at GRC) 

The VMOC system utilizes the following commercial-off- 
the-shelf (COTS) hardware and software: 

JBOSS® App server 5.1 Government Addition (GA) 

• Adobe ColdFusion® 9 Enterprise Edition 

• Oracle MySQL 5.1® 

• Use of Environmental Systems Research Institute 
(ESRI) ArcGIS® Map Server over the open 
internet 

o Other VMOC installations use this map 
server locally, but this was not in the cost 
scope of this project 

• Intel® Multicore-based Server / Windows® 2008 
Server 


3.2 System Access 

The VMOC uses numerous standard technologies and 
techniques to manage system access, user privileges and 
system assets. The VMOC supports the creation and 
maintenance of user accounts and personal information 
including definition and assignment of user roles and 
privileges to control access to individual web pages to 
specific users. Unauthorized access to pages is detected and 
access is disabled. The VMOC COTS stack includes robust 
web sessions management software that custom VMOC 
software leverages to manage access. Page requests from a 
user establish a web session where the VMOC can control 
login and user information. For this demonstration, users 
authenticate with a username and password. This is 
considered sufficient for this deployment. More 
sophisticated techniques such as biometrics or common 
access cards (CAC) could be deployed. Information is 
encrypted using account and session level keys. This 
supports DOD Security Technical Information Guides 
(STIGS) password selection standards. The session controls 
page navigation among authorized pages. Direct navigation 
to pages is supported, but unauthorized pages are blanked. 

3.3 System Flow Process 

The system flow process is illustrated in Figures 2, 4 and 5. 
Figure 2 shows the mission planning system; Figure 3 
shows the accounting system; and Figure 4 shows the 
external data provider interface. 

The mission planning system [Figure 2] is the heart of this 
VMOC instance. An authorized user, the Emergency 
Services Coordinator (ESC), will log into the VMOC and 
request sensor data. Currently, this is done via the Ad Hoc 
Tasking module by entering the longitude and latitude 
coordinates of the event of interest and the type of sensor 
data required and the time requirements for such data. The 



Figure 1 - Mission Planning 
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Ad Hoc Tasking module then passes this request on to the 
Optimized Constellation Management/Scheduler (OCMS). 
The OCMS runs various algorithms that review which 
resources are available to meet the required needs. The 
results are prioritized via rule-base algorithms and passed on 
to the Proposed Asset Usage Schedule (PAUS) module. 

The PUAS module is where the results (along with the 
associated costs of tasking a particular item) are presented to 
the ESC for validation and execution. This allows the ESC, 
or other authorized users, to be a gatekeeper prior to 
committing resources. Execution could be fully automated, 
but, the current thought is that the gatekeeper function, at 
least for USGS purposes, is highly desirable, if not actually 
a requirement in order to control commitments of resources 
(budgeted dollars). 

It is also possible to pre-define collection requirements 
rather than operate in Ad Hoc mode. The Collection 
Requirements module allows users to input pre-defined 
tasking processes and other implementation criteria into 
VMOC. An example of this would be to command VMOC 
to “follow a flood” as it progresses from an entry location 
on a river or flood plain and progresses down stream. The 
use of predefined tasking processes off-loads the need for 
continuous monitoring and manual entry from the ESC. As 
in the ad hoc case, the gatekeeper function can be 


implemented, requiring authorization prior to execution of 
tasking during the entire event. 

Future systems may also have fully automated “Tip and 
Cue” capabilities. Automated tip and cue was demonstrated 
in Phase 1 of the Secure Autonomous Automated 
Scheduling (SAAS) during late 2009 and early 2010 [2]. 
Here, USGS earthquake sensor triggers were used as the Tip 
in order to Cue the United Kingdom Disaster Monitoring 
Constellation satellite, UKDMC 1 to collect satellite 
imagery. 

The Tier One (1) Toolkit [Figure 3] is one of VMOC’s 
mission analysis tools. TIT is a web-based planning tool 
and guide for commercial, civil, academic, and possibly a 
limited number of DoD satellite solutions and provides 
operators with a satellite visualization capability. The Tier 
One Toolkit (TIT) capabilities monitor on-station space 
vehicles potentially available to meet urgent and on-going 
imagery and communication needs. TIT was developed for 
the Operationally Responsive Space (ORS) Office by the 
Naval Research Laboratory, intended to provide warfighters 
and decision makers with information about tasking 
opportunities for existing space systems. For purposes of 
the NASA demonstration, the Emergency Service 
Coordinator and other disaster response officials will be 



Figure 3 - Tier 1 Toolkit 
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Figure 4 - Accounting System 


granted access to the TIT. TIT allows authorized users to 
search for assets that may meet their needs, and to generate 
a satellite access request form which can be manually 
forwarded to the appropriate DoD, commercial, civil and/or 
approved foreign satellite systems authority for collection. 
TIT is designed such that non-space savvy users, as well as 
trained space system operators, can easily search for tasking 
opportunities. 

TIT primarily presents information about non-classified 
satellite assets in order for users to make informed decisions 
with regard to potential mission availability and then to 
request the proper authority to task the asset. TIT does not 
schedule or task any system or satellite directly. The system 
is designed to offer unrestricted access to several internal 
analysis tools, and controlled access to saved-user-data and 
mission administration functionality. It is important to note 
that the TIT in the NASA VMOC is on the open Internet 
and, therefore, directed only at non-classified systems. 

Figure 3 shows some of the graphical analysis available to 
users. Such tools are useful for highly technical users and 
can be hidden from the novice user who may be only 


interested in “what sensors are available” and “when they 
are available”. 

The Accounting System [Figure 4] receives the proposed 
tasking opportunities from the Proposed Asset Usage 
Schedule and presents the associated costs to the ESC. The 
Accounting Management and Financial Management 
module work together to ensure there are sufficient financial 
resources available prior to committing assets as well as 
keeping track of allocated resources. If sufficient funds are 
available and the gatekeeper authorizes the commitment, 
then the request is released to the vendor or other external 
supplier of sensor data. 

Once the gatekeeper releases a request for data products, the 
external data provider executes that request (or sends 
notification that the request cannot be executed). When the 
data order has been executed, the data provider sends notice 
to the VMOC that the data product is available (or, 
alternatively, pushes the data product to the VMOC). The 
system can be set up such that the data provider delivers the 
satellite data products directly to VMOC or, alternatively, it 
can send the data directly to a data repository (such as the 
USGS HDDS) or do both. At any time during the 
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transaction, the ESC can utilize VMOC to monitor the status 
of request. Once the satellite imagery has been generated 
and delivered, the VMOC Account Management module 
records the transaction and debits the appropriate account 
[Figure 5]. 

The original thought for data delivery was that since 
numerous External Data Providers are expected to 
eventually become a part of the USGS VMOC system, in 
order to simplify HDDS interfaces, the current 
implementation requires all data to be sent directly to the 
VMOC (VMOC then delivers all satellite data to a single, 
external HDDS data repository). However, upon discussions 
with USGS it became apparent that USGS already obtains 
sensor data from the various external providers directly and 
then massages that data and then makes the USGS standard 
formatted data product available to the appropriate users [5]. 
Thus, a decision was made to have the data product retrieval 
and delivery to the USGS Hazards Data Distribution System 
(HDDS) directly from DigitalGlobe rather that first passing 
to the VMOC. This was done for two reasons: 1) to improve 
time of delivery of vary large data sets; and 2) the interface 
already exists between HDDS and DigitalGlobe so there is 
no need to have the VMOC act as a common interface point. 

3.3. 1 VMOC / DigitalGlobe Interface 

1 . A custom spreadsheet is automatically generated by the 
VMOC that describes the desired collection. 

2. The VMOC transfers the spreadsheet to a DigitalGlobe 
static web site via File Transfer Protocol (FTP). 

3. DigitalGlobe will validate the request and determine 
whether or not the request can be processed and notify 
the VMOC. 

4. If the request was to be processed, but unforeseen 
circumstances resulted in cancellation of the task, 
DigitalGlobe will notify the VMOC so that the VMOC 
can notify the ESC and take appropriate actions to 
rectify the situation. 

5. Upon successful data collection, DigitalGlobe will 
notify VMOC that the data is available. 

6. VMOC will then notify USGS that the data product is 
available and update the Account Management System. 

7. USGS HDDS will retrieve the data directly from 
DigitalGlobe; create the appropriate HDDS data 
products from the sensor data; and notify users that the 
HDDS data products are available. 

4. Space Asset Selection 

This particular project had a relatively small budget 
(~$250K) and had a very rapid turn around due to lifetime- 
of-money budget issues - approximately 4 months start to 
finish. Thus, the space asset had to be readily available and 
relatively inexpensive. 

The first choice was to attempt to use a NASA asset, the 
EO-1 spacecraft. TheEO-1 spacecraft system was 


particularly attractive since the NASA Goddard Space 
Flight Center (GSFC) already had an autonomous scheduler 
for EO-1 that the VMOC could negotiate with [4]. In order 
to meet cost and schedule, GSFC engineers requested that 
VMOC interface to their system using available Open 
Source code that had been integrated into the EO-1 system. 
Unfortunately, it was determined that use of GSFC’s Open 
Source code in VMOC would require modifications to the 
existing system security accreditation. Such a modification 
could not be approved by DOD or the Intelligence 
Community (IC) without great pains and a year or more of 
effort. Key to this effort was the desire to leverage DOD and 
NASA investments in their respective VMOC 
infrastructure. Therefore, it was imperative to keep both the 
DOD VMOC and the NASA VMOC security and 
accreditation compliant. Given the modest budget and tight 
schedule constraints it was decided that the team needed to 
pursue other possible satellite systems to be used as the 
sensor system. 

The second choice was to try and use the second-generation 
United Kingdom Disaster Monitoring Constellation (UK- 
DMC2) platform from Surrey Satellite Technology Limited 
(SSTL). UK-DMC2 was particularly attractive because 
NASA GRC and General Dynamics (GD) already had an 
established relationship with SSTL and GD already had a 
Technical Assistance Agreement (TAA) with SSTL (which 
permitted GD to discuss and share regulated technical data 
with SSTL). To be a part of the current demo, SSTL needed 
to automate their operational system to allow machine-to- 
machine requests to SSTL’s Mission Planning System and 
full acknowledgment and acceptance of the request and data 
return. Unfortunately, negotiations with SSTL determined 
that the price was prohibitive for this project’s budget. 
However, such support remains highly desirable and will be 
considered in future VMOC enhancements. 

Finally, the team turned to DigitalGlobe for satellite 
imagery services. DigitalGlobe is a leading global provider 
of commercial high-resolution earth imagery solutions. In 
October of 201 1, DigitalGlobe was awarded a one-year 
contract at a funded level of $37.9 million by the U.S. 
Government via the National Geospatial-Intelligence 
Agency (NGA) under the NGA's new Enhanced Geospatial 
Intelligence (GEOINT) Delivery (EGD) program. The 
EGD program, with all options exercised, is expected to 
procure nearly SIB of commercial imagery products. 
Interested in fulfilling all of NGA’s requirements for a user 
access portal, DigitalGlobe established a relationship with 
GD to explore the potential use of GD’s VMOC technology. 
Thus, General Dynamics was able to negotiate an agreement 
with DigitalGlobe to use DigitalGlobe’s space assets for 
collection and provide a simple machine-to-machine 
interfaces within the available budget. Note, this DOD 
commercial imagery interface leverages a multi-year 
contract with NGA potentially worth over a billion dollars. 
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5. Current Concept of Operations 

The current system concept of operations (CONOPS) for 
this demonstration utilizes all of the major features of 
VMOC and provides interfaces to the Emergency Services 
Coordinator, satellite services provider and the U.S. 
Geological Survey ( USGS) Hazards Data Distribution 
System (HDDS). The HDDS already serves as a data 
repository that provides quick and easy access to imagery 
and geospatial data that supports emergency response and 
recovery operations. 

The operations flow procedure is illustrated in Figure 6 and 
outlined below: 

1 . Some disaster occurs and the USGS Emergency 
Services Coordinator (ESC) is notified. 

2. The ESC logs into the VMOC and is authenticated as a 
user. 

3. The ESC enters the disaster longitude and latitude, 
selects the type of sensor data needed, and the time 
period requirements. 

4. The VMOC determines which assets are physically 
capable of meeting the mission requirements and sends 
requests to the proper Controlling Entities (CEs) (in 
this case, DigitalGlobe) to obtain status. 

5. The CE(s) determines the sensor availability and 
returns a response to the VMOC. 


6. The VMOC notifies the ESC of available assets and 
the expected cost of services. 

7. The ESC chooses one, many, or all assets to fulfill the 
mission need. 

8. The VMOC requests a commit of those assets to the 
CE(s). 

9. The CE(s) commit their assets (or notes their inability 
to commit) and notifies the VMOC. 

10. The VMOC notifies the ESC which tasks were 
committed. 

1 1 . Once a task has been executed and the data product is 
available, the CE(s) notify the VMOC that the request 
has been executed and data is available. 

12. The VMOC notifies the ESC that the task has been 
executed; informs the HDDS that the data product is 
available and where to obtain the data; and updates the 
Accounting Management System. 

13. The HDDS obtains the sensor data directly from the 
data providers, creates the USGS HDDS standard data 
products, and stores that information on the HDDS. 

14. The ESC notifies field uses of the availability of the 
data and where and how to obtain it. 
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6. Proposed Future Enhancements 

The proposed enhancements to the VMOC are discussed 
prior to describing the Disaster Relief Operation CONOPS 
as many of these enhancements will likely be required for 
an operational system. 

6. 1 Digital Rights Management (DRM) 

For our purposes, Digital Rights Management (DRM) are 
access control technologies and techniques that are used by 
publishers, copyright holders, and individuals (or 
organizations) with the intent to limit the use of digital 
content transaction. DRM is any technology that inhibits 
uses of digital content that are not desired or intended by the 
content provider [6]. In the case of data generated in 
response to disasters, since it is often generated without cost 
to the disaster responders, it would be highly desirable to 
have a DRM enabled system to limit access to data products 
to authorized users only. What is required in VMOC or 
HDDS for DRM is something akin to an integrated library 
system (ILS). An ILS is used to track items and has modules 
for acquisitions (ordering, receiving, and invoicing materials 
cataloging, and circulation). Some items of interest include: 

• Locking digital data to specific computer(s), 

• Defining expiration times for digital data, 

• Stopping digital data from being shared and 
distributed across the Internet, 

• Defining watermarks for printing and/or viewing, 
and, 

• Restricting printing. 

It is important to note that much of the data obtained for 
disaster management is obtained via bilateral agreements 
whereby distribution is restricted to particular users and the 
lifetime of the data may be restricted. Therefore, digital 
rights management needs to be implemented in the final, 
operational system. The current operation for HDDS 
restricts data to particular users via access controls 
(username and password). However, once that data is 
downloaded, it could easily be redistributed either 
accidently or intentionally. Therefore, autonomous data 
destruction should also be considered to ensure full DRM 
compliance. 

6.2 Intelligent Collection Requirements 

It is highly desirable to have some intelligence and perhaps 
even some cognition in the Collection Requirements module 
whereby the system would be able to predict and follow 
events without continuous user supervision. For example, 
in the situation where flooding is occurring, it would be 
relatively easy to predict the movement of the flood or use 
additional sensors to monitor the movement of the flood and 
have the system autonomously request effects. The same 
could be possible for some weather and wild fire events. 
Automated “Tip and Cue” processes would also be helpful 
here. 


6.3 Expert vs. Non- Expert User interface 

The current Disaster Monitoring VMOC is designed to be 
used by an expert user. It assumes the ESC will have a 
working knowledge of the available assets (sensors), the 
type of sensor data required for various disasters, and the 
data timeliness needed. In the future, it would be extremely 
beneficial to capture such expertise in the VMOC in such a 
way that non-experts could readily use the VMOC to the 
same end. For example, an unsophisticated user may log 
into the system and indicate that a major earthquake has 
struck at a particular longitude and latitude. The system 
would respond back with a prioritized list of sensors that are 
normally requested for earthquakes and suggested 
timeliness for various sensor data. Also provided would be 
the sensor platform and associated costs. 

6.4 Marketing Response 

An additional feature would be to have VMOC suggest to 
users additional data that may be useful. Similar to the 
current marketing strategies employed by online shopping 
services, the VMOC could be designed to suggest services 
that other past users requested in response to similar 
circumstances. In other words, a user may request an 
optical image of a “wild fire” disaster event. VMOC would 
offer other related services, such as infrared imagery or 
other types of post-processing. 

7. Disaster Relief Operational CONOPS 

1 . A disaster occurs and the USGS Emergency Services 
Coordinator (ESC) is notified. 

2. The ESC logs into the VMOC and is authenticated. 

3. The ESC enters the longitude and latitude and selects 
the type of disaster. 

4. The VMOC returns a suggested list of sensor data 
often required for the particular type of disaster along 
with a suggested time period. 

5. The ESC selects the data product from the list 
provided. 

6. The VMOC determines what assets are available and 
sends requests to the proper Controlling Entity(ies) 
(CEs) (in this case, DigitalGlobe). 

a. There are cases where the interface between 
USGS and the requested resource is more or less 
manual by design or for political reasons. In this 
case the VMOC will generate the proper 
paperwork required and fax or email the request 
to the corresponding authority. In this case auto 
generating the forms ensures all forms are 
properly completed. 

7. The CE(s) determines the sensor availability and 
returns a response to the VMOC. 

a. There are many currently available assets where 
no feedback is provided or where that feedback 
consists of a phone call or fax. In such instances, 
the VMOC will have to simply assume that the 
asset is available, or some form of manual entry 
will be required. 
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8. The VMOC notifies the ESC of available assets and 
associated costs. 

9. The ESC can choose one, many or all assets. 

10. The VMOC requests a commit of those assets to the 
CE(s) via whatever means is required for the particular 
assets (e.g. machine-to-machine, fax, phone, etc...). 

1 1 . The CE(s) commit their assets or notes inability to 
commit and notifies the VMOC. 

12. The VMOC notifies the ESC as to which tasks were 
committed. 

13. The CE(s) notify the VMOC that the data products are 
available. 

a. At this point, the VMOC can debit the account 
and even generate payment. 

14. The VMOC notifies the ESC that the data product is 
available and notifies the HDDS that the data product 
is available and where the data is located. 

15. The HDDS obtains the sensor data directly from the 
data providers; creates the USGS HDDS standard data 
products; and stores that information on the HDDS. 

16. The ESC notifies field uses of the availability of the 
data and where and how to obtain it. 

In HDDS, field uses can obtain Really Simple 
Syndication (RSS) notifications by subscribing to 
the proper services. 

8. NASA’s Real Time Mission Monitor 

The NASA Real Time Mission Monitor (RTMM) is a 
situational awareness tool that integrates satellite, airborne 
and surface data sets; weather information; model and 
forecast outputs; and vehicle state data (e.g., aircraft 
navigation, satellite tracks and instrument field-of-views) 
for field experiment management [6]. The RTMM is 
implemented as a service oriented architecture based on 
community standards and protocols. The RTMM is a 
client/server-oriented architecture whereby users running 
client software subscribe to various services (information) 
from the server side RTMM system via the Internet. The 
server side RTMM obtains the requested information from 
both local and remote databases and returns that information 
to the field users. 

The RTMM currently does not task assets. Rather, it takes 
information from existing databases and redistributes that 
information in a useful format. The VMOC, on the other 
hand, does task assets and populates the databases. Thus, 
the two technologies are complimentary. 

For purposes of this task, the original thought was that we 
could tie the RTMM and VMOC together to task Unmanned 
Aerial Vehicles (UAVs). Unfortunately, the VMOC does 
not yet incorporate an active UAV interface (although it 
does tasking via a tool called “PRISM”, which is currently 
used by the DOD to task military UAVs). In the future, 
RTMM could be used to provide situational awareness in an 
emergency response situation while the VMOC could be 
used to task assets. For this emergency response 
demonstration, a simple hypertext link to the RTMM is 
provided to show functionality. 


9. Technology Readiness Level 
Assessment 

The overall NASA technology readiness level [8] for the 
VMOC must address the various aspects of its operations 
and related software tools. 

The VMOC that resides on the SIPRNet is currently tasking 
both the Tactical Satellite 4 (TacSat-4) and Operational 
Responsive Space Satellite 1 (ORS-1). TacSat-4 is a UHF 
Communication satellite for experimental operations. The 
launch date was September 27, 2011. Transition to 
operations expected in the spring of 2012. Thus, since this 
is currently an experimental system, it is at TRL 8. ORS-1 
performs visual and infrared imagery for the US Central 
Command (USCENTCOM). The satellite was launched 
June 22, 201 1 and is fully operational. Therefore, the ORS- 
1 VMOC is at TRL 9. Additional capabilities are in the 
VMOC pipeline for the near future. They include: 

• High Integrity Global Positioning Satellite (GPS) (TRL 
7), which uses Iridium signals to augment GPS for anti- 
jam, and is on the path for operational acceptance. 

♦ Tier One Toolkit (TRL 7) which is a suite of spacecraft 
analysis tools to search over a range of available 
commercial assets given specific collection criteria and 
determine what assets are available and when. This 
system is pending accreditation and is on track to go to 
the Space and Naval Warfare Systems Command 
(SPA WAR) as part of the Joint Space Operations 
Center (JSpOC) Mission System (JMS). 

The NASA Secure, Autonomous, Intelligent Controller for 
Integrating Distributed Emergency Response Satellite 
Operations system is at TRL 7 as it has been fully 
demonstrated in a relevant environment. The demonstration 
of this system to USGS, NGA, DOD TENCAP, and others 
has provided valuable insight into the security, accounting, 
and user feedback interfaces that need further work before 
the system can become fully operational. 
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AIST - Advanced Information Systems Technology 

ATI - Advanced Technology Insertion (under ESTO) 

CEOS - Committee on Earth Observing Satellites DOD - 

United States Department of Defense 

CE - Controlling Entity 

CONOPS - Concept of Operations 

COTS - Commercial-off-the-shelf 

DMC - Disaster Monitoring Constellation 

DRM - Digital Rights Management 

EGD- Enhanced GEOINT Delivery 

EROS - Earth Resources Observation and Science 

ESC - Emergency Service Coordinator 

ESTO - Earth Science Technology Office 

FTP - File Transfer Protocol 

GD-AIS - General Dynamics Advanced Information 

Systems 

GEOINT - Geospatial-Intelligence 

GOTS - Government-off-the-shelf 

GPS - Global Positioning Satellite 

GRC - NASA Glenn Research Center 

GSFC - NASA Goddard Space Flight Center 

HDDS - Hazards Data Distribution System 

HTTP - Hypertext Transfer Protocol 

ILS - Integrated Library System 

JSC - NASA Johnson Space Center 

JSpOC - Joint Space Operations Center 

NGA - National Geospatial-Intelligence Agency 

NRL- Naval Research Laboratory 

OCMS - Optimized Constellation Management/Scheduler 

RTMM - Real Time Mission Monitor 

ORS - Operationally Responsive Space 

ORS-1 - Operational Responsive Space satellite #1 

SAAS - Secure, Autonomous, Automated Scheduling 

SIPRNET - Secure Internet Protocol Router Network 

SOCOM - Space Operations Command 

SPAWAR - Space and Naval Warfare Systems Command 

SSTL- Surrey Satellite Technology Limited 

STIGS- DOD Security Technical Information Guides 

TacSat-4 - Tactical Satellite #4 

TIT -Tier One (1) Toolkit 

TAA- Technical Assistance Agreement 

TDRSS - Tracking and Data Relay Satellite System 

TENCAP - United States Air Force Tactical Exploration of 

National Capabilities 

TRL - Technology Readiness Level 

UAV - Unmanned Aeronautical Vehicle 

UKDMC-1 - Version 1 of the United Kingdom Disaster 

Monitoring Constellation satellite by SSTL 

UKDMC-2 - Version 2 of the United Kingdom Disaster 

Monitoring Constellation satellite by SSTL 

USCENTCOM - United States Central Command 

USGS - United Stated Geological Service 

USN - Universal Space Network 

VMOC - Virtual Mission Operations Center 

WGISS - Working Group on Information Systems and 

Services, supporting the Committee on Earth Observing 

Satellites 
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